fix(sonarcloud): declare all supported Python versions to Sonar - #61
fix(sonarcloud): declare all supported Python versions to Sonar#61williaby wants to merge 1 commit into
Conversation
sonar.python.version was 3.12, the single version CI builds with, while requires-python is ">=3.10,<3.15". SonarPython gates version-specific rules on ALL declared versions (PythonVersionUtils.areSourcePythonVersionsGreaterOrEqualThan is allMatch), so declaring only 3.12 satisfies every >=3.11 and >=3.12 gate and raises those rules against code that must still run on 3.10. No S6794/S6796 issue is open in SonarCloud today, so this is preventive: the misconfiguration fires the first time this codebase grows a construct one of those rules covers, and then reports something the project cannot act on without dropping 3.10. Sets the new sonar-python-version input (ByronWilliamsCPA/.github#291) and bumps the uses: pin to the commit that introduces it, since passing an input the callee does not declare fails a reusable workflow at startup. Also syncs sonar-project.properties, which CI overrides via -D but SonarLint in the IDE reads. python-version stays 3.12: it feeds actions/setup-python and is a separate concern from the versions the source must remain compatible with. Verified: actionlint rc=0; pre-commit scoped to the two changed files passes every hook that matches them.
WalkthroughSonarCloud configuration now analyzes Python 3.10 through 3.14. The reusable workflow reference was updated, and comments document CI override behavior. ChangesSonarCloud version alignment
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
There was a problem hiding this comment.
Pull request overview
Aligns SonarCloud/SonarLint Python version configuration with the project’s declared compatibility range (requires-python = ">=3.10,<3.15"), so version-gated SonarPython rules don’t incorrectly assume 3.11+/3.12+ features are always allowed when the code must still run on 3.10.
Changes:
- Updates
sonar.python.versionto declare all supported source versions (3.10–3.14) for local/IDE (SonarLint) analysis. - Updates the SonarCloud reusable workflow pin and passes
sonar-python-versionso CI analysis uses the same supported-version set.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| sonar-project.properties | Sets sonar.python.version to 3.10–3.14 and documents that this should stay in sync with CI/IDE analysis expectations. |
| .github/workflows/sonarcloud.yml | Bumps reusable workflow ref and supplies sonar-python-version with the full supported-version list. |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@sonar-project.properties`:
- Around line 26-29: Update the comment above sonar.python.version in
sonar-project.properties to remove the claim that this setting affects local or
IDE SonarLint analysis. Keep the explanation that CI overrides the value and
that the supported Python-version range must remain aligned with
requires-python.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 88d73005-7919-4bd3-8b51-d11675766d44
📒 Files selected for processing (2)
.github/workflows/sonarcloud.ymlsonar-project.properties
| # Versions the SOURCE supports, matching requires-python (">=3.10,<3.15"). CI overrides this | ||
| # via -Dsonar.python.version from the sonar-python-version input, so this key only affects | ||
| # local and IDE (SonarLint) analysis. Keep the two in sync. | ||
| sonar.python.version=3.10,3.11,3.12,3.13,3.14 |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n --hidden --glob '!**/.git/**' \
'sonar\.python\.version|sonarlint|sonarqube' .Repository: ByronWilliamsCPA/python-libs
Length of output: 683
🌐 Web query:
SonarQube for IDE sonar-project.properties properties applied sonarlint sonar.python.version
💡 Result:
SonarLint for IDEs does not directly use the sonar-project.properties file to configure analysis parameters like sonar.python.version [1][2][3]. The sonar-project.properties file is designed specifically for SonarScanner CLI, which is used for full server-side analysis [1][3]. In SonarLint, the recommended way to manage configuration is through Connected Mode [4]. When you bind your IDE project to a project in SonarQube or SonarCloud, SonarLint retrieves the configuration (including quality profiles and rules) directly from the server [4][3]. This ensures that your IDE analysis remains consistent with the server-side analysis [3]. Regarding sonar.python.version specifically: - Purpose: This parameter informs the Python analyzer about the expected Python version to improve the accuracy of the analysis (e.g., standard library handling and symbol resolution) [5][6][7]. - Usage: It is intended for use in sonar-project.properties or via SonarScanner CLI during full analysis [6][8][9]. - SonarLint Behavior: SonarLint does not read this property from local configuration files [3]. If you are using Connected Mode, the server-side configuration should ideally handle the environment settings [3]. If you are not in Connected Mode, SonarLint relies on its internal default settings and does not currently support local overrides of this parameter via property files [1][2]. If you need to ensure consistency between your IDE and your CI analysis, the best practice is to ensure your project is properly bound in Connected Mode to your SonarQube/SonarCloud instance [4][3].
Citations:
- 1: https://community.sonarsource.com/t/sonarlint-on-vs-use-sonar-project-properties/6095
- 2: https://community.sonarsource.com/t/sonarlint-connected-mode-and-sonar-project-properties-file/62714
- 3: https://community.sonarsource.com/t/select-source-file-folder-and-file-excludes/119204
- 4: https://community.sonarsource.com/t/configuring-connecting-mode-in-vscode-with-sonar-project-properties-file/101615
- 5: https://community.sonarsource.com/t/python-3-related-code-smells-still-reported-after-setting-sonar-python-version-to-2-7/66858
- 6: https://docs.sonarsource.com/sonarqube-server/analyzing-source-code/languages/python
- 7: https://docs.sonarcloud.io/sonarqube-cloud/analyzing-source-code/languages/python
- 8: https://docs.sonarsource.com/sonarqube-server/9.9/analyzing-source-code/languages/python
- 9: https://github.com/SonarSource/sonar-scanner-python/blob/master/CLI_ARGS.md
🌐 Web query:
SonarLint Python 3.14 Sonar rule Python version support sonar.python.version
💡 Result:
SonarLint and the broader Sonar ecosystem (including SonarQube Server and SonarQube Cloud) provide full support for Python 3.14 [1][2][3]. The support for Python 3.14 was introduced to enable analysis of new language features, including specific rules (such as S7931, S7941, S7942, S7943, and S7945) designed to ensure best practices when using Python 3.14 capabilities [4]. Regarding configuration, you can use the sonar.python.version parameter to specify the Python version(s) your project supports [1][3][5]. This helps the analyzer provide more precise results and silence irrelevant issues [1][6]. Key details for sonar.python.version: - Purpose: It allows you to define which Python versions are compatible with your code, ensuring the analysis is tailored to the correct language features [1][3]. - Format: It accepts a comma-separated list of versions in the "X.Y" format (e.g., sonar.python.version=3.13, 3.14) [1][5][7]. - Usage: This parameter can be set in your sonar-project.properties file or provided via the CLI during analysis [1][5][6]. For IDE integration, including SonarLint, ensure your plugin is updated to the latest version to access the most recent rules and support for Python 3.14 [4].
Citations:
- 1: https://docs.sonarsource.com/sonarqube-server/analyzing-source-code/languages/python
- 2: https://www.sonarsource.com/knowledge/languages/python/
- 3: https://docs.sonarcloud.io/sonarqube-cloud/analyzing-source-code/languages/python
- 4: https://community.sonarsource.com/t/sonarqube-supports-python-3-14-with-new-rules/153139
- 5: https://docs.sonarsource.com/sonarqube-server/2026.2/analyzing-source-code/languages/python.md
- 6: https://docs.sonarsource.com/sonarqube-server/2025.3/analyzing-source-code/languages/python
- 7: https://docs.sonarsource.com/sonarqube-cloud/analyzing-source-code/languages/python
Remove the SonarLint sonar-project.properties claim.
sonar-project.properties is for SonarScanner runs, and SonarLint does not apply sonar.python.version from this file. Keep the CI value aligned, but remove “affects local and IDE (SonarLint) analysis” or document a supported connected-mode/IDE configuration instead.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@sonar-project.properties` around lines 26 - 29, Update the comment above
sonar.python.version in sonar-project.properties to remove the claim that this
setting affects local or IDE SonarLint analysis. Keep the explanation that CI
overrides the value and that the supported Python-version range must remain
aligned with requires-python.
Problem
sonar.python.versionwas3.12, the single version CI builds with, while this project'srequires-pythonis">=3.10,<3.15".SonarPython gates version-specific rules on all declared versions:
PythonVersionUtils.areSourcePythonVersionsGreaterOrEqualThanis anallMatch. Declaringonly
3.12therefore satisfies every>= 3.11and>= 3.12gate, so those rules fireagainst code that must still run on 3.10.
Preventive, not curative
SonarCloud reports 0 open
S6794/S6796issues here today. The misconfiguration is realbut latent: it fires the first time this codebase grows a construct one of those rules covers,
such as a PEP 695
type X = ...alias, and then reports a finding the project cannot act onwithout dropping 3.10 support. Flagging this so a green result is not read as evidence the
change was unnecessary.
Fix
3.14 joined the org supported set in ByronWilliamsCPA/.github#292, and
requires-python's<3.15ceiling admits it.python-versionstays3.12. It feedsactions/setup-pythonand is the version the projectbuilds and tests with, a separate concern from the versions the source must remain compatible
with. Conflating the two is what caused this.
Why the pin moves too
sonar-python-versionis new in ByronWilliamsCPA/.github#291 and does not exist in thepreviously pinned revision. Passing an input the callee does not declare fails a reusable
workflow at startup, so the pin moves to
4bd2d7c, the squash commit of #291 onmain.Also in this change
sonar-project.propertiesis synced to the same list. CI overrides it via-D, but SonarLintin the IDE reads it, so leaving it at
3.12would keep local analysis raising what CI doesnot.
Verification
actionlintrc=0pre-commitscoped to the two changed files: every matching hook passesSummary by CodeRabbit